【レポート】マルチアカウント戦略におけるセキュリティとガバナンスのアーキテクチャ設計 #reinvent #SID331

こんにちは、虎塚です。

re:Invent 2017のセッション「Architecting Security and Governance Across a Multi-Account Strategy」(マルチアカウント戦略におけるセキュリティとガバナンスのアーキテクチャ設計) についてレポートします。時間の都合で現地参加が叶いませんでしたので、動画を視聴しました。

発表は、AWSのSam ElmalakさんとThomson ReutersのBen Woodwardさんでした。

• AWS re:Invent 2017: Architecting Security and Governance Across a Multi-Account Stra (SID331) - YouTube

個人が学習目的でAWSを使うならいざしらず、エンタープライズの組織が1個のAWSアカウントですべてのシステムをホストしようとするのは無理があります。このセッションは、マルチアカウント管理のための考え方と、世界的な大企業での実例の両方を学べる、非常に興味深い内容でした。最後にはアクションプランと称して、作業用チェックリストのサンプルも紹介されました。

むかしむかし (小話)

あなたは森に住む赤ずきんちゃんで、おばあさんを訪ねていきます。ときどきオオカミに会ったり会わなかったりします。あなたは、クラウドについて噂を聞きました。数分でセットアップできて、なんでもサーバにデプロイできるそうです。

おばあさんは、いつも素晴らしいパイとクッキーを作ってくれます。おばあさんのパイとクッキーをオンライン販売するために、あなたはAWSにアカウントを作り、サーバとバスケットを設定しました。パイとクッキーを出荷し、売上が入りはじめました。

7人の小人がその話を聞きつけて、彼らが採掘しているゴールドをオンラインで売ることにしました。ついでに、Tシャツも売り始めました。

ところが、ある日突然販売が止まりました。あなたは人々が休日なのかと思いましたが、違いました。AWSセキュリティチームから、 あなたのアカウントがBitcoinのマイニングに使われている と報告がありました。サーバは停止されてしまいました。

あなたはCloudTrailを使っていませんでしたので、何が起きたのかわかりませんでしたが、とにかくアカウントを分けることにしました。パイとクッキーを売るアカウントと、Tシャツを売るアカウントです。今度はCloudTrailも有効にしました。

また売上が上がり始めました。しかし、再び販売が止まりました。ほどなくして、悪い女王があなたのアカウントに出入りしていることを突き止めました。あなたは ルートアカウントを使っていて、女王とクレデンシャルを共有していた のです。

女王はAWSアカウントを止めて、あなたが持っているすべてのリンゴを要求しました。毒を注入して、白雪姫に渡すためです。

もちろん、赤ずきんであるあなたは良い人なので、りんごを渡さないことを決めました。すると女王はすべてのアカウントを止め、CloudTrailログを消してしまいました。 あなたは破産した ので、もはやおばあさんを訪ねる時間はありません。いったいどうやって末長く幸せに暮らせばよいのでしょうか。

このセッションで学ぶこと

さて、破産したり誰かに情報を盗まれたりしないように、次のことを学びましょう。

• エンタープライズ向けのマルチアカウントのフレームワーク
• 戦略を実装するためのアクションプラン

AWSアカウント

AWSアカウントは、emailとパスワードを使ってセットアップします。各アカウントは、次の事項について高いレベルで分離されています。

• セキュリティとリソースの境界 は、アカウントが違えば完全に分離される。
• APIの実行回数の制約やスロットリング は、アカウントごとに設定される。
• 料金請求 もアカウントごとにおこなわれる。
  • ネットワークトラフィックは、リソースへのタグ付けで分離できない。請求を完全に分離する唯一の方法は、アカウントを分けること。

もし1つのアカウントしか使っていなければ、これらは分離できません。

アカウントモデル

多くの顧客は、1個のAWSアカウントから始めます。一方で、数千のアカウントを持つ顧客もいます。そして、多くの顧客は、その中間規模の量のアカウントを持っています。

アカウントの数が多くなればなるほど、アカウント管理もデータの分配も難しく、複雑になります。

なぜ1個のアカウントでは不十分か

1個のアカウントだけを使用する状態は危険です。人々は他の人の設定を上書きしたり、他の人が使っているインスタンスを削除したり、クレデンシャルを漏洩させたり、githubにコミットしてしまったりします。

• 複数のチームがある場合、それぞれのチームは異なる責任とビジネスモデルを持っているため、分離が必要。
• データ保存の管轄や準拠するコンプライアンスモデルが、チームによって異なる場合がある。
• 1つのアカウントですべてを管理する時、すべてのデータを暗号化しようと考えるかもしれないが、インターネットに公開するサービスを持っている場合、すべてのデータを暗号化するのは適切でない。
• 複数のチームは、異なるビジネスプロセスを持つ。
• 何にいつどれくらい使ったかの請求情報を分離する必要がある。

ケーススタディ: Thomson Reuterのマルチアカウント戦略

(08:00-)

Thomson Reutersは、世界規模の企業です。税金、法律、金融のプロフェッショナルに情報と商品を提供しています。100カ国以上に組織を持ち、12,000人以上の技術系専門職を抱えています。

つまり、 12,000人以上がAWSアカウントにアクセスする必要がある状況 とお考えください。スケール性と適切な運用が必要です。

データセンターとの接続

AWSとオンプレミスのデータセンターとの接続には複数のDirect Connectを利用しています。Thomson Reutersのシステムは、自社ビジネスユニットから大量のアクセスを受けています。

• AWSリージョン
  • データの物理的な格納場所: 新しく制定される法律に準拠する必要あり
  • 新しい成長機会: 素早くマーケットにデプロイする必要あり
  • レイテンシー: 最小限に抑えたい。
• AWSアカウント
  • プロジェクトごとの分離: コンプライアンス準拠、センシティブなデータの保護
  • AWS APIの制約: システムごとに設定したい
  • 請求の分離: タグ付けできないリソースも含め分離して管理

上のような事項を考慮しつつ、データセンターを何箇所接続するか、リージョンを何個使うか、アカウントを何個作るかなどを決めています。

ネットワークトポロジー

スケール性の観点からネットワークを見てみましょう。アカウント数の膨張や、ネットワークの要求、Amazonによって設定されているハードリミットも考える必要があります。

Thomson Reutersのネットワークでは、データセンターとビジネスユニットの接続にAWS Direct Connectを利用しています。現時点では50アカウントをDirect Connectで利用できます。顧客管区用との接続にはVPNを利用しています。ここにも、実際の接続数にはVPNソフト等の制約があります。また、VPC同士の接続に、VPCピアリングも利用しています。これは共有サービスやセキュリティツールのために重要です。ここにも、接続できるVPC数に制約が存在します。

このようにスケール性が要求されるため、戦略を進化させながら、新規アカウントをオンデマンドに作成する必要があります。コストやオーバーヘッド、いくつかの制約を克服して、アカウントがボトルネックにならないようにしなければなりません。

アカウントの作成

新しいアカウントは、コンソールから手作業で作ることもできますが、幸いOrganizations APIを使ってプログラムから作ることができます。Thomson Reutersでは、次のようにしています。

1. Organizationsアカウントから、APIを利用して新規アカウントを作成する。
2. Organizationsアカウントから、新規アカウントのクロスアカウントRoleを使用する。(Assume)
3. Organizationsアカウントから、新規アカウント内をセットアップする。たとえば、VPCのプロビジョニングなどの基本的なネットワークレイヤーを作成する。
4. 新規アカウントをOrganizationsアカウントのOU (organizational unit) に移動する。これで、新規アカウントをグループ化して (たとえばビジネスユニットごとに) 扱うことができる。
5. 最後に、Organizations Roleを削除する。特権アカウントとして多くの権限を持っているため。

この方法を採用したのは、次の理由によります。

• アカウント作成のセルフサービス化：自動化できるところは自動化して、注力すべきところに集中
• サービスコントロールポリシー (SCPs) の利用: アクセス権限を集中的に制御

アカウントのインフレーション

増え続けるアカウントに対して、次のことをします。

• rootのクレデンシャルを大切に保管する
• サービスマネジメントの記録を作成する
• コーポレートアイデンティティプロバイダーとフェデレーションで連携する
  • 初期オペレーションロールを作成
• VPCとネットワークを設定する
  • AWS Direct ConnectとVPCピアリングを使う
• セキュリティ制御レイヤーとロギングを設定する
  • ロギングの有効化、セキュリティと管理用IAM Roleの作成

ポイントは、次のとおりです。

• ワークフローツールを使おう
  • 異なる種類のアカウントを作成する際、各アカウントで何をデプロイする必要があるかを明示すると便利
• 環境をCloudFormationで動的に構築しよう
  • 新しいAZが追加された時などに対応できるように、静的なテンプレートやハードコーディングを避ける
• Configurationドリブンにする
  • 手動で設定変更をせず、単一のconfig fileを管理することに集中する

エンタープライズに必要なアカウント群

エンタープライズ企業がAWSアカウント管理をはじめたその日に、すぐ作成する必要があるアカウントについて見ていきましょう。

ロギングアカウント

さて、上のような新規アカウントの作成プロセスができたら、エンタープライズのアカウント群を構築しはじめることができます。

まず必要なのは、 ロギング用アカウント です。このアカウントは、CloudTrailのログ、VPC Flow LogsやS3バケットのアクセスログなどを保管するために使います。

共有サービス用アカウントやセキュリティツール用アカウントで取得したログを、ロギング用アカウント一箇所に集約しましょう。

• 正とする唯一のソースとして、ロギング用アカウントを扱う
• セキュリティ確保のために一箇所に限定する
• このアカウントへのアクセスは厳しく制限する
  • 一度設定を終えたら、このアカウントに誰もアクセスできないようにする
• ログ保存には、環境やビジネスユニットに応じて複数のS3バケットを使う
• セキュリティツールなどがログを必要とした時に、S3バケットにread-onlyのアクセス許可を与える

管理者アカウント

管理者アカウントを作成する際の方針は、次のとおりです。

• たとえ開発者を信頼していても、かならず検証する
• すべてのアカウントを横断的・一元的に管理する手段が必要

AWS Trusted AdvisorやAWS Configを使いましょう。何か起きた時にアクションを強制するよりも、通知するようにします。また、管理者アカウントとその他のアカウントには、read-onlyとreadwriteのIAM Roleをそれぞれ作成し、管理者アカウントからAssumeRoleで利用しましょう。

管理者アカウントは、個々のアカウントを可視化し、ハブとして機能します。

セキュリティアカウント

SecOpsのためのセキュリティアカウントを用意しましょう。このアカウントでは次のことをします。

• ログの処理: ロギングアカウントからログを取得
• セキュリティツールのホスト
• インシデント管理

共有サービス用アカウント

エンタープライズに最低限必要な最後のアカウントは、共有サービス用アカウントです。元は、共有ネットワークサービスのために設計しました。このアカウントでは次のことをします。

• AWS Direct Connect
• DNSサービス
• 踏み台ホスト
• ネットワーク監視
• AMIの作成

このアカウントへアクセスする必要があるユーザは、時間がたつとともに増えますので、次の方針を守りましょう。

• ビジネス的に重要なサービスは分離しましょう
• より制限されたアクセスを提供しましょう

これは、障害が発生した際の影響を局所化することにつながります。

ビジネスユニットに必要なアカウント群

次に、ビジネスユニットごとに用意するアカウント種別を見ていきましょう。

サンドボックスアカウント

まず、ビジネスユニットごとのサンドボックスアカウントを用意します。

• チームが新しいことを試すための場として
• データセンターと接続しない
• マルチテナント
• 権限を制限する: 多くのリソースを同じビジネスユニットのメンバー間で共有するため
• 既存のアカウント追加の仕組みに載せる

しかし、このようなサンドボックスに対して、開発者から、先に紹介したアカウント作成手順で自動設定される基本的なネットワークレイヤー、たとえばVPCやルーティングテーブルにも学習のためにアクセスしたいというフィードバックがあるかもしれません。

そこで、開発者ごとのサンドボックスアカウント も用意します。これは12,000人の技術専門職がいたら、12,000個のアカウントを作成することを意味します。もちろん大量のアカウントになりますが、この環境は個々の開発者の学習と実験のために必要です。

• 学習と実験のための場として
• データセンターと接続しない
• シングルテナント
• フルパーミッション
• 最小のアカウント追加の仕組みに載せる
  • マスターアカウントのconsolidated billing下に入れる

SDLC (Software Development Life Cycle) アカウント

SDLCアカウントは、ビジネスアプリケーションをビルドしてデプロイするためのアカウントです。

昨年の本セッションでは、ビジネスユニットごとに、本番アカウントと非本番アカウントの2個のアカウントを用意することを提案しました。各開発者には、非本番環境のreadwriteアクセス権を与え、本番環境のread-onlyアクセス権を与える想定でした。しかし、この設定では、誰かが想定外の変更をしうることが分かりました。

今年のセッションでは、非本番環境をDev、本番環境をProdに変更した上で、本番にデプロイする前にテストするための Staging アカウントとビジネス継続性のための Disaster Recovery アカウントを加えた4個のアカウントを用意することを提案します。最悪の事態が起きた時に、本番環境にログインして課題を分析したり、変更を元に戻したりする必要がないようにして、単にフェールオーバーすればよい状態にするためです。

各アカウントは、同様のアカウント作成プロセスにしたがい、次のように設定します。

• rootのクレデンシャルを大切に保管する
• 基本的なネットワーク構成をプロビジョニングする
• セキュリティ制御の設定をする
• IAMフェデレーションを使用する
• 基本のIAM Roleを作成する

方針は、次のとおりです。

• 小さなアカウントセットから開始して、各ビジネスユニットと会話を続ける
  • どんな新しいアプリケーションがリリース予定で、どんな環境が必要かを確認しよう
  • どんなユースケースが将来必要かを確認しよう
• 必要とされるリソース分離の種類を特定する

IAMを使ったマルチテナントリソースの分離

次の方針を用います。

• IAMでリソースの分離を提供する
• タグによる条件式とリソース名をIAMポリシーに設定する
  • 例: 特定のアプリケーション名をタグに設定されたEC2に対して、TerminateInsntances APIの使用を禁止する
  • 例: 特定のアプリケーション名を名前に設定されたIAM Roleに対して、PassRoleアクションを許可する

これには、オーバーヘッドが発生することと、(タグベースのアクセス制御をサポートするAWSサービスにしか使えない戦略であるため) 100%の網羅性はないという欠点があります。

しかし、一度ポリシーを作成して、従業員用のテンプレートを定義すれば、その後は簡単に設定を管理できます。

CI/CD アカウント

各ビジネスユニットのために作成する最後のアカウントは、CI/CD用アカウントです。SDLCアカウントの紹介で見てきたようにDev, Staging, Prodなどのアカウントがあるとして、それらのどこにCI/CDパイプラインを置くかは難しい問題です。デプロイのために環境をまたぐ設定が必要ですが、アクセス制御は厳格にしたいからです。そこで、CI/CD用アカウントを用意し、次のことをします。

• CI/CDパイプラインをホストする
• カオスエンジニアリング (アプリケーションの自動復旧テスト) を稼働させる

CICDアカウントには、ビルド成果物 (アーティファクト) を保存するデータストアと、ビルドパイプラインをプロビジョニングします。各SDLCアカウント (Dev, Staging, Prod) には、デプロイ用のIAM Roleを用意します。

1. CICDアカウントでアーティファクトをビルドする
2. 各SDLCアカウントに次のことをする
   1. AssumeRoleを使ってアクセスする
   2. CloudFormationで環境をデプロイする
   3. CodeDeployでアプリケーションをデプロイする

アカウント管理の開始地点

昨年に紹介した構成では、Organizations Masterアカウントの下で、エンタープライズアカウントとしてセキュリティアカウントと共有サービス用アカウントがあり、ビジネスユニットアカウントとしてサンドボックス、Dev, Prodアカウントがありました。

Thomson Reutersではその後の教訓から、まず、エンタープライズアカウント群として、ログを一元管理するための ロギングアカウント と、横断的な管理を提供するための 管理者アカウント を追加することを提案します。さらに、 Direct Connect用アカウント と DNS用アカウント も追加することで、障害を局所化できます。

次に、ビジネスユニットアカウント群として、より本番に近い環境でテストするための Stagingアカウント と、最悪のシナリオが発生した時のための DRアカウント を追加しました。CI/CDアカウントも追加しました。

最後に、開発者アカウント群として、1人に1アカウントのサンドボックスアカウントを追加しました。

複数AWSアカウント

(39:00-)

複数AWSアカウントの長所と短所を見てみましょう。長所は次のとおりです。

• セキュリティとリソースの分離を実現できる
• 障害発生を局所化できる
• 請求をアカウント単位に単純化できる

一方、短所は次のとおりです。

• 設定の作成と分配が必要になる
• セットアップと運用にオーバーヘッドがある
• アカウント間をまたぐセキュリティポリシーがますます複雑になる

ゴール

複数AWSアカウントの戦略を考えるにあたっては、原則またはゴールを考えるところから始めましょう。次の状態がゴールです。

• 自動化されている -- レプリケートを容易にするとともに、人間によるアクセスを減らす
• スケーラブルである
• できるだけセルフサービスにする
• ブロッカーではなくガードレールを提供する
• 監査可能である
• 柔軟であること
  • 新しいサービスや新しい方針が登場した時に、このモデル自体を変更できることが最も重要

アカウントセキュリティ - Day 1

ベースラインになる要求事項は、次のとおりです。

• AWSアカウントクレデンシャル (Rootアカウント) を管理する
• すべてのリージョンでCloudTrailを有効化する
• エンタープライズRoleの割り当て
• フェデレーションの利用: 組織への従業員の入退場と連携して動作させる
• セキュリティアカウントや監査のためのクロスアカウントRoleの用意
• アカウントに適用するアクションとコンディションの定義

どのアカウントを作成すべき？

• Organizationマスターアカウント
• エンタープライズ
  • ロギングアカウント
  • セキュリティアカウント
  • Direct Connectアカウント
  • 共有サービスアカウント
  • 請求アカウント
• ビジネスユニット
  • サンドボックスアカウント
  • Dev, Pre-Prod (Staging), Prod用アカウント
  • その他、あなたの組織で必要なアカウント

これらの各アカウントについて、ざっくり見ていきましょう。

AWS Organizationsマスターアカウント

• データセンターに接続しない
• サービスコントロールポリシーを設定する
• Consolidatedビリングの親アカウント
• ボリュームディスカウント適用対象
• プロビジョニングするリソースは最小限にする
• アクセスを制限
• 設定作業が終わったらOrganization Roleを削除すること!

サービスコントロールポリシーとして、次のようなポリシーを作成しましょう。

• CloudTrailのロギングの停止を 禁止 するポリシー
  • cloudtrail:StopLogging
• VPCへのInternet Gateway等のattachを 禁止 するポリシー
  • ec2:AttachInternetGateway
  • ec2:CreateInternetGateway
  • ec2:AttachEgressOnlyInternetGateway
  • ec2:CreateVpcPeeringConnection
  • ec2:AcceptVpcPeeringConnection

ロギングアカウント

• ログを格納するAmazon S3でバージョニングを有効にする
• バケットのアクセスを制限し、MFA Deleteを有効にする
• CloudTrail logs
• セキュリティログ
• 正とする単一のソースにする
• アクセスを厳しく制限する

セキュリティアカウント

• (状況に応じてオプションとして) データセンターと接続する
• セキュリティツールや監査ツールを導入する
• CloudTrail、AWS Configを設定する
• クロスアカウントのreadwrite Roleを許可する
• アクセスを厳しく制限する

Direct Connect / Networkアカウントの作成

Direct Connectを利用する場合は、障害発生箇所を局所化するために専用のアカウントを作成します。

• ネットワークチームが管理する
• AWS Direct Connectやネットワークサービスを設定する
• アクセスを制限する

共有サービスアカウントの作成

• データセンターと接続する
• DNSサービスを設置する
• LDAP / Active Directoryを設置する
• 共有サービス用VPCを設置する
• デプロイツールを設置する
  • ゴールデンAMI
  • パイプライン
• スキャンインフラストラクチャ
  • 非アクティブなインスタンス
  • 正式でないタグ
  • スナップショットライフサイクル
• 監視を設定する

請求用アカウント

• Organizationマスターアカウントへのアクセスを減らす
• ビリングレポートを生成する
• メトリクスとレポートを利用する
• 最適化とReserved Instanceの管理をする
• アクセスを制限する

内部監査用アカウントの作成

組織がPCIやHIPAAなどに準拠する必要がある場合は、内部監査用のアカウントも用意します。

• コンプライアンス準拠
• 必要なログへのread-onlyアクセスを提供する
• アクセスを制限する
• 参考セッション ENT324: Automating and Auditing Cloud Governance and Compliance in Multi-Account Environments

開発者用のサンドボックスアカウント

• データセンターに接続しない
• イノベーションのための場
• 月額使用料金の上限を設定する
• 自治性を重んじる
• 実験の場

ビジネスユニットのアカウント群

• 必要とされる分離レベルに基づいて設定する
• 開発のライフサイクルに合わせる

Devアカウント

• 開発とイテレーションを素早く回せるようにする
• コラボレーションをおこなう
• ソフトウェア開発ライフサイクルのステージに合わせる

Pre-Prod (Staging) アカウント

• データセンターに接続する
• 本番とできるだけ同じように設定する
• ステージングとしての利用
• 品質保証チームの利用
• 自動デプロイの実施

Prodアカウント

• データセンターに接続する
• 本番アプリケーションをデプロイする
• Pre-Prod環境からデプロイする
• アクセスを厳しく制限する

チームの共有サービス用アカウント

• 有機的に成長することを想定する
• ビジネスユニット/チームで共有する
• Product-specificなサービスを設置する
• データレイクを設置する
• ビジネスユニット間で横断的に使われる共通ツールやサービスを設置する

チームのサンドボックスアカウント

• データセンターに接続しない
• データセンターからも接続されない
• イノベーションや実験のための場として使う

サンドボックス / イノベーション アカウント間のパイプライン

開発者同士のコラボレーションのために、次のような使い方ができます。

• 開発者のサンドボックスアカウントからPoCアカウントへのアクセスを許可する
• 開発者のサンドボックスアカウントから、ほかのビジネスユニットの開発者アカウントへのアクセスを許可する

特別、例外的なアカウント

• ここまで説明したフレームワークにこだわらず、柔軟に作成、設定する
• 必要なコンプライアンスや標準を守る (HIPAA、PCIなど)
• 必要に応じて、追加の分離やセキュリティコントロールを用意する (PII)
• 複雑なプラットフォームやプロダクトに対応する

マルチアカウントの方針

次のアカウントを作成しましょう。

• Orgs
• Logging
• Security
• Shared Service
• Billing Tooling
• Sandbox
• Dev
• Pre-Prod
• Prod

次のステップ

やるべきことをリストにしました。

• タグ付け戦略の定義
• 自動化戦略の定義
• 組織アカウントの作成
• ロギングアカウントの作成
• セキュリティアカウントの作成
• 共有サービス用アカウントの作成
• 請求ツール用アカウントの作成
• 開発者サンドボックス用アカウント (群) の作成

アクションプラン

より具体的なアクションプランは次のとおりです。チェックリストとして活用してください。

• 自動化戦略を定義する
• タグ付け戦略を定義する
  • AWS Tagging Strategies – AWS Answers
• IPアドレス空間戦略を定義する
  • データセンターや他のアカウント/VPCとの重複を避ける
• 組織マスターアカウントを作成する
• ロギングアカウントを作成する
  • CloudTrailとAWS Config用のバケットを作成する
  • MFA deleteを有効化する
  • バージョニングを有効化する
  • バケットポリシーでアクセス制限を定義する
  • ロギングアカウントにログを送信するように、rootアカウントでCloudTrailを有効化する
  • 組織マスターの作成とロギングの間で発生するアクションに備えて、CloudTrailログをコピーする
• セキュリティアカウントを作成する
  • セキュリティアカウントとrootアカウント、ロギングアカウント間のクロスアカウントRoleを作成する
  • read-onlyのRole
  • readwriteのRole (できるだけ少ないパーミションで作成)
  • CloudTrailを有効にして、ロギングアカウントにログを送る
  • セキュリティチェックのためにセキュリティツールを導入し、Lambda関数を作成する
• AWS Direct connectアカウントを作成する
• 請求ツール用アカウントを作成する
  • 共通チェックリストを実施 (後述)
• 共有サービスアカウントを作成する
  • 共通チェックリストを実施 (後述)
  • DX/VPNとデータセンター間の接続を作成する
  • 共通チェックリストを実施 (後述)
  • 一般的なサービスを起動する
  • Directory service
  • DNS
• ビジネスユニットアカウントの作成 (stage/devサイクルごとに)
  • BU/チームのサンドボックスアカウントを作成する
  • 共通チェックリストを実施 (後述)
  • BU/チームのDevアカウントを作成する
  • 共通チェックリストを実施 (後述)
  • DX/VPNを経由してデータセンターのdevネットワークに接続する
  • 共有サービスにVPCピアリングで接続する
  • BU/チームのNon-Prod/Pre-Prodアカウントを作成する
  • 共通チェックリストを実施 (後述)
  • DX/VPNを経由してデータセンターのnon-prodネットワークに接続する
  • ネットワークのプロビジョニング
  • 共有サービスにVPCピアリングで接続する
  • BU/チームのProdアカウントを作成する
  • 共通チェックリストを実施 (後述)
  • DX/VPNを経由してデータセンターのprodネットワークに接続する
  • 共有サービスにVPCピアリングで接続する
• 開発者個人のサンドボックスアカウントを作成する
  • クロスアカウントのセキュリティ用Roleを用意する
  • 他の環境からの分離と非接続を維持する
  • MFA/rootをセキュアに保管する
• 内部監査アカウントを作成する
  • 共通チェックリストを実施 (後述)

共通チェックリスト

• Rootクレデンシャルをセキュアに保管する
  • MFAを使う
  • 複雑なパスワードを使う
  • ローテーションポリシーを策定する
• まだであれば、Organizationsマスターアカウントにメンバーとして接続する

• CloudTrailをすべてのリージョンで有効にして、ロギングアカウントにログを送信する

• AWS Configを有効にして、ロギングアカウントに送る
• セキュリティのためのread-onlyクロスアカウントRoleを作成する

• セキュリティのためのreadwriteクロスアカウントRoleを作成する

• (IPアドレス空間が重複しないように) VPCを作成する

• アカウントでフェデレーションを有効にする
  • 参考: SEC306: Choose Your Own SAML Adventure: A Self-Directed Journey to AWS Identity Federation Mastery
• Roleとアクセスポリシーを定義する
• 連絡先情報として、グループメールと電話番号を使用する
• 共有サービスとともにVPCピアを利用する

• すべてのアカウントにプリフィックスを利用した命名規則に関するポリシーを追加する

  • 例: 「security*」で始まる名前のLambda関数へのアクセスを禁止する
• CIS Foundations Benchmarkをレビューし、適切な対処をする

おわりに

マルチアカウント フレームワーク を標榜するだけあって、さまざまなユースケースを考慮したアカウントが登場しました。大量のアカウント種別に目を奪われますが、このセッションで重要なのは、レポートの前半でお伝えした「考え方」です。障害発生を局所化すること、コンプライアンスを準拠すること、それでいて開発者の利便性は守ること等の要求から、マルチアカウント管理の方針 をまず策定し、組織に合わせて具体的に必要なアカウントを計画していきましょう。

それでは、また。